前言

上回提到，PVE 中的 Device IO 主要分為三種，其中 QEMU Guest 到 KVM Module 中的溝通會造成過多的性能浪費。

QEMU 搞錯了什麼？

之前說過，一個 KVM 想要模擬 IO，便是在接受到 IO Trap 後再行處理，隨後，將這個 IO 相關的資訊交給 QEMU 模擬成 Host 看得懂的版本。

降為來說：

我們可以將 Guest 視作為員工，想要把一份中文文件交給老闆核准，
老闆 Host 看不懂中文就把文件退了回去。
員工就只能外找一個翻譯幫他翻這份文件，然後再送回給老闆核准後繼續工作。

我們可以發現，這樣的方式確實有效且能夠達到目的。

VirtIO

但隨著 Guest 變多、要翻譯的裝置變複雜：

老闆 Host 就決定自己娉請一個翻譯，
坐在自己的辦公室裡，凡是送到他面前的文件都給翻譯官翻一下。
這樣員工不用自己花錢請翻譯，員工開心了、雙方也不用浪費來回的交流間。

於是 VirtIO 就這樣誕生了。

VirtIO 透過前端後端的方式處理翻譯問題：

• 前端負責在 Guest 內接受要翻譯的需求，
• 後端則在 Host 上完成這些翻譯需求的實作。

這樣的好處是，只要在不同的 Guest 上實現一個 VirtIO 驅動、也在 Host 實現一個翻譯接口，便能夠以較高的效率完成 IO 虛擬化的作業！

最後，我們來完整看一次 VirtIO 的工作方式：

1. 後端初始化對應的 queue 內容
2. 前端 VirtIO Driver 初始化 virtqueue 結構
3. 利用 virtio_config_ops 讓 virtdevice 知道要看哪個 virtqueue
4. virtqueue_ops 利用相應的操作與後端溝通完成操作

結語

VirtIO 雖然會需要在 VM 內安裝相應的驅動，不過已經預設安裝在多數的 Linux 中，所使用 Linux VM 時，VirtIO 不失為一個好選擇！